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ABSTRACT 
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A weak  logic  of  programs  is  a formal  system  in  which  statements  that  mean  the  program  halts 
cannot  be  expressed.  In  order  to  prove  termination,  we  would  usually  have  to  use  a stronger 
logical  system  In  this  paper  we  show  how  we  can  prove  termination  of  both  iterative  and 
recursive  programs  within  a weak  logic  by  adding  pieces  of  code  and  placing  restrictions  on 
loop  invariants  and  entry  conditions.  Thus,  most  of  the  existing  verifiers  which  are  based  on  a 
weak  logic  of  programs  can  be  used  to  prove  termination  of  programs  without  any  modification. 
We  give  examples  of  proofs  of  termination  and  of  accurate  bounds  on  computation  time 
that  were  obtained  using  the  Stanford  Pascal  program  verifier. 
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Proof  of  Termination  within  a Weak  Logic  of  Programs 

by 

David  Luckham  and  Nori  Suzuki 


1.  INTROr  VICTION. 


A weak  logic  of  programs  is  one  in  which  statements  that  "a  program  halts" 
cannot  he  expressed.  Such  a logic  has  been  given  by  [Hoare  69,71]  and  its  proof 
theory  has  been  defined  and  studied  in  [Igarashi,  London  & Luckham](referred  to  as 
ILL),  [Hoare  & Lauer],  [Cook].  Other  recent  papers  have  been  devoted  to 
strengthening  this  logic  so  that  questions  of  termination  are  expressable;  e.g. 
Dijkstra’s  notion  of  weakest  precondition  [Dijkstra],  and  various  suggestions  for 
introducing  well-orderings  into  the  assertion  language. 

Here  we  give  a simple  application  of  the  method  of  Virtual  Programming  which 
permits  strong  statements  of  termination  (e.g.  program  A halts  and  Q is  true)  to  be 
deduced  from  weak  statements  (if  A halts  then  Q is  true)  by  means  of  the  good  old 
law  of  excluded  middle.  (Remark:  the  notion  of  virtual  program  in  intuitive  terms  is 
simply  code  added  to  an  actual  program  which  has  no  effect  on  the  actual  values  of 
the  result  parameters.)  The  method  requires  no  change  whatever  in  the  weak  logic, 
and  employs  exactly  the  same  automated  techniques  that  are  currently  used  to  verify 
all  manner  of  properties  of  programs  [ILL,  Suzuki  75a, b,  von  Henke  & Luckham].  This 
permits  strong  proofs  of  correctness  (i.e.  termination  and  consistency  with 
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specifications)  to  be  obtained  using  the  present  verification  systems  based  on  the 
weak  logic.  Similar  ideas  have  been  put  forward  by  Knuth  [Knuth],  in  which  he 
showed  how  one  can  prove  the  termination  of  extended  Euclid’s  algorithm  as  the 
byproduct  of  the  correctness  proof  using  Floyd’s  method. 

Virtual  program  has  been  used  previously  to  document  programs  in  certain 
tricky  situations  (e.g.  where  the  documentation  uses  data  structures  not  used  by  the 
actual  program,  such  as  history  sequences  [Clint],  or  data  structures  destroyed  by 
the  actual  program  [v.Henke  & Luckham]).  More  recently  it  has  been  used  to  prove 
complexity  bounds  on  program  computations  [Farmwald].  The  technique  seems  to 
present  a natural  approach  to  proving  dynamic  properties  of  programs  (i.e.  properties 
of  the  computations  themselves  as  distinct  from  the  final  results).  Termination  is  one 

of  these  dynamic  properties. 

Essentially,  most  programs  halt  for  simple  reasons,  and  the  programmer  usually 
knows  these  reasons.  What  is  needed  is  a natural  way  of  permitting  him  to  state  his 
reasons.  Our  proposal  here  is  simply  to  introduce  virtual  program  counters  into  the 
program.  The  function  of  these  counters  is  to  "count"  the  number  of  computation 
steps  that  are  executed.  Each  path  in  the  program  must  have  added  to  it  an 
assignment  statement  which  increments  the  counter  proportionally  to  the  length  of 
the  path.  The  programmer  must  also  add  inductive  assertions  stating  in  effect  that 
the  values  of  the  counters  are  bounded.  Presumably  he  has  an  idea  of  a reasonable 
upper  bound,  and  that  is  all  that  is  necessary.  The  problem  of  proving  termination 
within  the  usual  weak  logic  then  becomes  merely  another  verification  problem 
—namely  the  proof  of  the  boundedness  of  the  counters  in  the  augmented  program. 
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There  is  one  "catch".  The  counters  must  account  for  every  possible  loop  and 
recursion  Cue.  every  potential  source  of  infinitely  long  computation),  otherwise  a 
correct  weak  statement  will  not  imply  termination.  A test  for  this  provision  can 

easily  be  automated. 

In  section  2 we  illustrate  the  method  and  the  "catch"  by  simple  examples.  An 
outline  of  a rigorous  justification  is  given  in  Section  3,  and  actual  results  using  our 

present  verifier  [ILL,  Suxuki75a,b]  are  included  in  Section  4. 

To  simplify  mailers,  we  have  restricted  the  discussion  to  Pascal  programs 
containing  Assignment,  Conditional,  and  While  statements,  function  calls,  and 
recursive  procedure  calls.  The  extension  of  the  method  to  GoTo’s  and  other 
statements  is  obvious.  Also,  we  have  assumed  that  the  reader  has  an  acquaintance 
with  some  of  the  literature  on  verifiers  based  on  the  weak  logic  of  programs  (see  the 

references). 
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2.  THE  METHOD. 


Our  method  involves  the  use  of  very  simple  virtual  programs.  Virtual  program 


is  defined  rather  loosely  as  a set  of  instructions  imbedded  into  the  program  to  be 


verified  so  that  it  does  not  interfere  with  the  original  program  (often  called  the 


actual  program).  We  shall  use  only  virtual  assignment  statements,  and  their  left 


hand-sides  will  be  required  to  be  ghost  variables— variables  which  are  not  used  in  the 


original  program.  No  other  kind  of  modifications  will  be  allowed.  It  is  clear  that  the 


addition  of  such  instructions  cannot  change  the  behaviour  of  the  actual  program  on 


the  actual  program  variables. 


As  an  example  let  us  look  at  the  following  program  for  multiplication  by 


addition. 


Program  1. 


ENTRY:  a,b:lNTECER; 

xea; 

y*-0; 

while  x*0  do 
begin 
x^x-l; 
yey+b  ■ 
end. 

EXIT:  ysa*b; 


If  we  want  to  measure  the  time  taken  to  compute  multiplication  with  the  assumption 


that  the  assignment  statement  and  testing  both  take  a unit  computation  time,  we  can 


modify  the  program  by  introduction  of  virtual  program  as  follows, 
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Program  2. 


ENTRY:  a,b:lNTEGER; 

x-a; 

y-0; 

counter*-2; 

while  x^0  do 
begin 
x«-x-l; 
y*-y+b; 

counter«-counter+3 

end. 

EXIT:  y*a*b  a counter-3*a*b+2; 

Suppose  we  can  prove  within  the  weak  logic  of  programs  that  program  2 augmented 
by  the  new  assignment  instructions  satisfies  the  new  EXIT  condition.  The  value  of 
the  counter  in  the  EXIT  is  a function  of  the  input  parameters  only.  So,  we  will  have 
proved  that  whenever  the  augmented  program  stops  the  counter  is  bounded  by  a 
bound  that  is  given  before  the  computation  starts.  Now  assume  that  we  have  put  the 
virtual  assignments  "in  all  the  right  places"  so  that  every  possible  computation  path 
contains  an  assignment  which  increments  the  counter  by  the  number  of  instructions 
on  the  path.  Then  we  will  have  proved  that  either  the  actual  program  1 will  stop 
within  a number  of  steps  less  than  the  bound,  or  it  will  compute  forever.  This  would 
give  us  a tool  for  proving  bounds  on  the  complexity  of  computations  of  programs 
using  standard  verification  techniques. 

There  is  one  problem:  the  user  is  responsible  for  putting  virtual  assignments  of 
the  form  counter«-f(counter)  that  increment  the  counter  correctly  in  a sufficient 
number  of  places.  Having  done  this,  verifying  the  computation  bounds  becomes  a 
problem  of  verifying  a statement  about  the  augmented  program  in  the  weak  logic,  and 
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the  verifier  can  be  used  to  aid  in  solving  it.  Note  that  we  do  not  have  to  extend  the 


weak  logic  in  any  way. 

We  might  ask  whether  we  cannot  prove  termination  at  the  same  time.  This 
simple  thought  presents  another  problem.  See  the  following  example, 

Program  3. 

ENTRY  TRUE; 
x<-0; 

counter*-!.; 
while  x>0  do 
begin 
x*-x+l; 

counter«-counter+2 

end. 

EXIT  counteKl; 

This  program  certainly  does  not  terminate.  But  it  is  easily  proved  to  be  weakly 
consistent  with  the  output  assertion,  COUNlERcl.  And  the  counter  is  clearly 
couming  all  possible  computation  steps.  The  weak  correctness  proof  goes  as  follows. 
We  take  the  inductive  assertion  Xi0  as  invariant  of  the  loop.  Then,  three  verification 
conditions  are  generated  corresponding  to  three  paths  in  the  program. 

(1) .  TRUE-*0}0. 

(2) .  X^0aX^0  ->  X+1S0. 

(3) .  Xi0A-Xi0  -*  COUNTERS. 

They  are  all  valid.  Condition  (1)  requires  that  when  the  control  reaches  the 
while-statement,  the  invariant  will  be  satisfied  intially.  And  (2}  guarantees  that  X^d  is 
the  invariant  of  the  loop.  Condition  (2)  is  valid  since  the  antecedent,  namely 
X^0A-Xi0,  is  a contradiction;  that  is,  the  path  to  the  EXIT  is  never  executed. 


I 

I 

I 

The  question  of  proving  termination  is  really  asking  under  what  conditions  a 
weak  statement  about  a program  with  a virtual  counter  ("if  P stops  then  counterCb") 
implies  a strong  statement  ("P  must  stop  in  <b  steps").  As  is  evident  from  the  above 
example  such  implications  are  not  always  valid.  In  order  for  a weak  statement  to 
imply  a corresponding  strong  statement  all  iterative  statements  must  have  an 
invariant  assertion  stating  that  the  counter  is  bounded.  We  shall  call  these  "bound 
assertions". 

In  our  example,  the  inductive  assertion  about  the  while  loop  does  not  even 
contain  the  counter.  If  we  try  to  force  the  proof  above  to  be  a proof  of  termination, 
we  have  to  give  a stronger  loop  assertion  so  that  if  the  program  does  not  terminate 
and  the  control  repeats  the  loop  indefinitely,  this  assertion  eventually  becomes  false. 
Then,  the  verification  condition  corresponding  to  the  loop  is  no  longer  valid. 

The  question  is,  "can  we  always  find  such  strengthening  of  the  loop  invaliant?" 
And  the  answer  is  ,Hyes."  The  expression  which  we  have  to  add  is  COUNTERCg(X), 
where  X is  a set  of  input  values  of  program  parameters.  This  assertion  gives  the 
upper  bound  for  the  value  of  COUNTER. 

The  method  for  While  Statements: 

Each  while  statement  is  associated  with  a variable,  COUNTER,  which  does  not 
appear  in  the  actual  program.  A COUNTER  may  be  associated  with  many  while 
statements.  For  each  while  statement,  the  user  must  add  to  the  while  body  a counter 
assignment,  COUNTER«-f(COUNTER,X0),  where  f is  a strictly  increasing  integer 
valued  function  and  X0  is  a set  of  variables  not  occurring  in  the  actual  program.  The 
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u^r  must  also  add  an  inductive  assertion,  COUNTER<g(X0),  where  g is  a well  defined 


L 


1,1 

I 


t . 


junction  of  XO , to  the  While  statement. 


The  same  kind  of  technique  can  be  used  to  prove  termination  of  procedures 
with  recursive  calls.  Here,  the  potential  source  of  infinite  computation  is  the 
execution  of  arbitrarily  many  calls.  The  role  of  the  counter  will  be  to  "count"  the 
number  of  recursive  calls  by  being  incremented  by  COUNTER  «•  ((COUNTER, X0),  f a 
strictly  increasing  integer  valued  function,  each  time  a call  occurs.  So  we  have  to 
place  the  counter  assignments  where  they  will  be  executed  whenever  procedures  are 
evoked.  One  place  which  meets  that  requirement  is  the  beginning  of  the  procedure 
body.  Also  we  need  to  add  bound  assertions  that  will  become  false  if  the  depth  of 
procedure  calls  exceed  a certain  level.  The  best  candidate  is  the  ENTRY  condition  of 
the  procedu  re.  The  counter  is  introduced  as  an  additional  VARIABLE  parameter  of 
the  procedure  since  it  must  be  global  to  every  call. 

We  note  that  the  bound  assertion,  say  COUNTER  < g{X0)  , must  be  fixed  for 
all  calls;  therefore  XO  must  not  contain  any  parameters  appearing  in  procedure  calls 
otherwise  the  bound  would  change  with  the  actual  values  of  those  parameters.  We 
can  think  of  XO  as  being  initial  values  of  parameters  of  the  outermost  procedure  call. 

Below  we  give  an  example. 


Program  4 


procedure  factor ial (var  X ; N) ; 
ENTRY  N>0; 

EXIT  X-NJ ; 

i f N«0  then  X «-  1 else 


begin 


factorial (X.N-l) ; 


-i 

\ 
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end. 


X - N*X 


* 


This  is  a procedure  which  calculates  factorial  N and  returns  the  result  in  X.  The 
entry  and  the  exit  conditions  are  N i 0 and  X B N!  respectively.  We  change  the 
program  with  COUNTER  assignments. 

Program  5 

procedure  factor i a l (var  X.COUNTEF;  N); 

ENTRY  N>G  a COUNTERING  a COUNTtH+N-NG; 

EXIT  X-N ! ; 

begin 

COUNTER  - COUNTER  + 1; 
i f N»6  then  X *•  1 el  se 
begin 

factorial (X, COUNTER, N-l); 

X - N*X 


end. 

Notice  the  new  entry  condition  contains  not  only  a bound  assertion,  COUNTERING, 
but  also  an  inductive  assertion  stating  an  invariant  relationship  between  COUNTER 
and  values  of  the  parameter  N in  successive  calls.  Notice  also  that  NO  has  been 
introduced  so  that  the  bound  contains  no  parameter  of  the  procedure;  NO  is  the 


initial  value  of  N at  the  outermost  procedure  call.  So  what  we  are  going  to  prove  is 

N>0  a COUNTER+N=N0  a COUNTERING 
{ COUNTER  - COUNTER  + 1; 
i f N«0  then  X ♦-  1 else 
begin 

factorial (X, COUNTER, N-l) ; 

X - N*X 
end.  ) 

X - N! 


with  the  assumption  that 

Y>0  a COUNTER+Y-N0  a COUNTERING  l factorial  (X, COUNTER, Y)  ) X-Y! 

Using  techniques  for  proving  weak  correctness  of  procedure  call  [Hoare71,  ILL, 
Su2uki75b],  verification  conditions  are 
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(I)  N^OaCOUNTER*N-N0aCOUNTER<N0  ^(N«0  3 1=0!). 

(II)  N^Oa(COUNTER+N*N0aCOUNTER<N0  a N-1>0aCOUNTER+1+N-1»NOa 

COUNTERcN0a{X00*(N-1)!  ^ N*X00!«N!)) 
which  are  all  valid.  So  the  actual  program  4 is  correct  and  also  terminates. 

The  Method  for  Recursive  Procedures 

Each  procedure  declaration  is  associated  with  a variable,  COUNIER,  not 
appearing  in  the  actual  program.  Then  (1)  COUNTER  is  introduced  as  a new 
VARIABLE  parameter  of  the  procedure,  and  all  calls  are  correspondingly  modified; 
(2)lhe  user  must  place  at  the  beginning  of  the  procedure  body,  a counter  assignment, 
COUNTER  - f(COUNTER,X0),  where  f is  strictly  increasing  and  XO  is  a set  of 
variables  not  appearing  in  any  procedure  body;  (3)  the  user  must  add  a bound 
assertion,  COUNTER  £ g«0),  to  the  ENTRY  condition  of  the  procedure. 


s? 


3.  JUSTIFICATION  OF  THE  METHOD. 


We  are  going  to  show  that  this  method  of  adding  virtual  program  counters  to 
while  statements  and  procedures  with  recursive  calls  is  sufficient  to  prove 
termination.  That  is,  a proof  of  weak  correctness  of  the  augmented  program 
guarantees  the  termination  of  the  actual  program.  We  have  omitted  the  case  for  goto 
statements  but  we  can  treat  them  likewise. 

(i)  While  statements. 

The  augmented  program  for  while  statements 

WHILE  C DO  S 

is 

WHILE  C DO 

( COUNTER  - f (COUNTER,  XO)  ; S) . 

where  f(COUNTER,X<^  is  an  integer  valued  strictly  increasing  function,  that  is 
COUNTER  < f(COUNTER,m 

and  XO  is  a set  of  nev  variables  not  occurring  in  S.  The  form  of  the  invariant  of  the 

loop  ( or  the  inductive  assertion  ) must  be 

i A COUNTER  £ g(X0 ) where  1 is  any  Boolean  assertion. 

Now  we  are  going  to  prove  that  if  the  augmented  program  of  this  form  with 
the  given  inductive  assertion  is  verified  then  the  actual  program  terminates.  Various 
proofs  of  the  soundness  (i.e.  semantic  consistency)  of  the  weak  logic  of  programs 
have  been  given  (see  [Hoare  & Lauer],  [Igarashi,  London  & Luckham],  [Cook]).  These 
proofs  construct  a model  (essentially  an  abstract  interpreter  for  the  programming 
language)  with  the  property  that  any  statement  about  a program  that  is  provable  in 
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this  logic  is  true  when  the  program  is  "run"  on  the  interpreter.  This  means  for 
example,  that  if  we  can  prove 

i { while  L do  A } I in  the  logic  of  programs, 

I being  a Boolean  assertion  invariant  of  the  loop,  then  when  "while  L do  A"  is  run  on 
the  abstract  machine,  the  computation  state  at  the  end  of  every  execution  of  the 
loop  will  satisfy  1. 

We  shall  show  that  the  provability  of  weak  statements  about  programs 
augmented  by  counters  according  to  our  method  implies  that  the  computations  of 
those  programs  on  the  abstract  machine  halt.  We  present  our  argument  with  some 
degree  of  informality  since  we  do  not  wish  to  burden  the  reader  with  the  f^.^al 
details  of  the  model  here.  We  shall  simply  refer  to  a "standard  machine"  which  the 
reader  can  imagine  is  an  interpreter  for  the  axiomatic  semantics  of  Pascal. 

Proof 

Suppose  the  augmented  program  for  a simple  while  statement  as  shown  with  the 
given  inductive  assertion  is  proved.  Suppose  also  that  the  program  does  not  terminate 
when  run  on  the  standard  machine.  We  are  going  to  show  that  this  assumption 
produces  a contradiction.  We  are  going  to  number  the  values  of  COUNTER  so  that 
COUNTER  is  the  value  of  COUNTER  when  the  control  goes  around  the  loop  i times. 

Since  the  program  does  not  terminate,  we  are  going  to  have  an  infinite  sequence  of 
values, 

COUNTER  COUNTER  , ... 

0 n 
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Because  of  the  assignment  statement 

COUNTER  - f(COUNTEMO), 

which  takes  place  between  two  successive  values  of  COUNTER’S,  we  have  the 
relation 

COUNTER  • f(COUNTER  }X0). 

\*  1 > 

However,  f is  strictly  increasing  and  i'r.o  it  is  an  integer  function;  therefore, 

COUNTER  i COUNTER  + 1. 

i*i  > 

From  the  above  relation 

COUNTER  ^ COUNTER  + n 

n 0 

So  for  any  integer  k we  can  select  m such  that  COUNTER  > k.  This  contradicts  the 

rr. 

fact  that  the  loop  invariant  is  of  the  form 

I a COUNTER  £ gWO),  which  is  true  for  every  iteration  and 
e(X0)  must  remain  constant  throughout  the  computation. 

So  the  program  must  terminate. 

(ii)  Recursive  procedures. 

The  augmented  program  for  procedure 
procedure  MX) ; B 

is 

procedure  MXjvar  COUNTER); 
begin 

COUNTER  - f (COUNTER,  XO)  \ . 

B 

end. 

The  function  f must  be  strictly  increasing  as  was  the  case  in  (i).  The  bound  assertion 
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is  now  added  to  the  entry  condition  of  the  procedure  , which  must  take  the  same 
form  as  in  the  case  of  while  statements. 

Proof 

Assume  first  that  B contains  no  while  loops  nor  calls  to  procedures  other  than 
k.  Suppose  the  augmented  program  with  input  assertions  of  the  form 
1 a COUNTER  c g (XO) 
can  be  verified.  That  is 

1 a COUNTER  < g(X0)  l begin  COUNTER  «-  f (COUNTER,  XO);  B end  } O 

is  provable  with  the  assumption  that 

I a COUNTER  < g (XO)  { k(X)  } 0 . 

Suppose  also  the  program  does  not  terminate.  Then  the  depth  of  recursive  calls  to 
this  procedure  is  infinitely  large.  In  this  case,  we  are  going  to  number  the  values  of 
COUNTER  at  the  beginning  of  the  procedure  so  that  COUNTER^  is  the  value  of 

COUNTER  at  the  i-th  level  of  procedure  call  in  the  current  calling  sequence.  So  we 
have  a sequence  of  values 

COUNTER  , ... , COUNTER  , ... 

8 n 

Because  of  the  assignment  statement 
COUNTER  ♦-  f(COUNTER,X0) 

at  the  beginning  of  the  procedure  body  so  that  it  is  always  execute  after  a call,  we 
have  the  following  relation 

COUNTER  * f(COUNTER,X0), 

i*i  • 

for  all  i.  As  in  the  previous  case,  for  any  integer  k,  we  can  choose  m such  that 
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COUNTER  > k. 

m 

This  is  a contradiction  because  at  each  procedure  call 
I a COUNTER  £ g(X0) 

must  hold  just  at  the  entry  to  the  body.  Note  that  g(X0'  must  remain  constant  over 

all  calls  because  X0  does  not  contain  any  program  variables. 

The  above  arguments  for  a single  loop  and  a single  recursive  procedure  can  be 
generalized  for  nested  loops  and  mutual  recursive  procedures.  Essentially,  if  there  is 
an  infinite  computation  of  an  augmented  program  with  n counters,  one  of  those 
counters  will  be  incremented  infinitely  many  times. 


4.  EXAMPLES. 


All  proofs  below  were  obt  lined  using  the  Stanford  Pascal  Verifier.  This  system  is 


implemented  in  LISP  and  runs  on  a PDP-10  in  about  50K  words  of  memory.  Tfe  main 


references  for  details  of  this  verifier  are  [Igarashi,  London  & Luckham,  Suzuki  a,b]. 


The  first  example  is  Dijkstra’s  square  root  program  which  computes  square  root  of  N. 


The  problem  here  is  to  verify  both  that  the  program  halts  and  computes  an  integer 


approximation  to  the  square  root  of  N.  The  program  has  been  augmented  by 
operations  on  the  virtual  variable  COUNTER.  Termination  of  the  square  root 
program  is  verified  by  proving  the  bound  assertion  on  COUNTER  for  the  augmented 
program.  The  documentation  is  expressed  in  terms  of  user-defined  concepts  such  as 
"B2  is  a power  of  four"  and  "the  integer  logarithm  base  4 of  B2".  Notice  that  the 
EXIT  condition  implies  that  the  loop  is  executed  at  most  ILOC4(B20)  times,  where 


B20  is  the  intial  value  of  parameter  B2. 


PASCAL 

ENTRY  (N>0)  a (B2>N)  a P0UER_0F_F0UR (B2) a(B2-B20)  j 
EXIT  (0  < A)  a (A*A  5 N)  a (N  < (A+1)*(A+1)) 
a (COUNTER  <;  IL0G4  (B20) ) ; 


BEGIN 
A2  ; - 0 
AB  0 
COUNTER 


INVARIANT  POWER _0F  FOUR (B2) a(AB*AB  - A2*B2i a(AB*0) a (B2>0) 
a(A2+2*AB+B2>N)a(A2<N) 
a ( IL0G4 (B2) +C0UNTER-I L0G4 (B20) ) 
a (COUNTER  S IL0G4 (B20) ) 

WHILE  1 * B2  00 
BEGIN 

AB  AB  OIV  2; 

B2  B2  OIV  4; 


i 
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A ; = 
END.; 


AB; 


T : - A2  + 2*AB  + B2; 
COUNTER: -COUNTER+1; 

IF  T £ N THEN 
BEGIN 
A2  T; 

AB  AB  + B2 

ENO 

END; 


***** 


FOR  THE  HA IN  PROGRAM 

THERE  ARE  3 VERIFICATION  CONDITIONS 


n i 

(0<N  & 

N<B2  & 

POUER.OF  FOUR (B2)  & ' 

B2=B20 

POWER_OF_FOUR (B2)  & 

0*0=0*B2  <S 
0<0  & 

0<B2  & 

N<0+2*0+B2  & 

0<N  & 

0<ILOG4 (B20)  & 

3LOG4 (B2}+0=1LOG4(B20)  & 

(~1  -B200  & 

POUER_OF_FOUR (B200)  & 
AB00*AB00«A200*B200  & 

0<AB00  & 

0<B200  & 

N<A200+2*AB00+B200  & 

A208<N  & 

COUNTER00<3  L0G4 (B20)  & 

I L0G4 (B200) +COUNTER00- I L0G4 (B20) 

-♦ 

0<AB00  & 

AB00*AB00<N  & 

N<  f AB00+1 )* (AB00+1 ) & 
COUNTER00<ILOG4 (B20) ) ) 


U 2 

(-■A2+2*(AB  OIV  2)  +B2  01 V 4sN  & 
-1»B2  & 

P01*jER  OF  FOUR  (B2)  & 


AB*AB=A2*B2  & 

0<AB  & 

0<B2  & 

N<A2+2*AB+B2  & 

A2<N  & 

COUNTER<ILOG4(B20)  & 

I L0G4 (B2) +C0UNTER-IL0G4 (B20) 


POWER  OF_FOUR(B2  01 V 4)  & 

(AB  0 1 V 2) * (AB  OIV  2)-A2*(B2  01 V 4)  & 
0<AB  DIV  2 & 

0<B2  OIV  4 & 

N<A2+2* (AB  OIV  2)+B2  OIV  4 & 

A2<N  & 

COUNTER+1 < IL0G4 (B20)  & 

IL0G4 (B2  OIV  4) +C0UNTER+1-IL0G4 (B20) ) 


(A°+2* (AB  OIV  2) +B2  OIV  4<N  & 
-1=B2  S 

POUER_OF_FOUR  (B2)  & 
AB*A8=A2*B2  & 

0<AB  & 

0<82  & 

N<A2+2*AB+B2  S 


A2<N  & 


C0UNTER<IL0G4 (820)  & 

IL0G4 (B2) +COUNTER- I L0G4 (B20 ) 


PQUER_OF_FOUR (B2  DIV  4)  & 

(AB  Olv  2+B2  DIV  4) * (AB  DIV  2+B2  DIV  4)- 

(A2+2* (AB  OIV  2) +B2  OIV  4)*(B2  DIV  4)  & 

0<A;  OIV  2+B2  DIV  4 & 

N<A2+2^AB  OIV  2)+B2  DIV  4+2*(AB  OIV  2+B2  OIV  4)+B2  DIV  4 & 
A2+2* (AB  OIV  2) +B2  OIV  4sN  & 

COUNTER+1<ILOG4(B20)  & 

IL0G4 (B2  OIV  4) +C0UNTER+1-1LQG4 (B20) ) 


These  verification  conditions  all  simplify  to  TRUE  using  the  SIMPLIFIER  with  the 
lemmas  (AXIOMS  and  GOALS)  in  the  GOALFILE  below.  The  total  time  for  the 


complete  verification  is  39  CPU  seconds. 


The  lemmas  describe  properties  of  POWER_OF_FOUR(X),  X DIV  Y,  EVEN(X),  and 
ILOG4(X),  and  are  supplied  by  the  user.  They  are  written  in  a form  which  indicates 
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how  they  are  to  be  used  by  the  SIMPLIFIER  [Suzuki  a].  To  read  them  as  logical 
statements  simply  ignore  all  occurrences  of  A lemma  of  the  form  "AXIOM  A«*B" 
means  "A-B".  "GOAL  A SUB  B"  means  "B-A". 

With  this  advice  readers  should  be  able  to  understand  the  lemmas  (while  those 
aquainted  with  our  previous  reports  will  also  understand  how  they  are  used  by  the 
SIMPLIFIER  in  the  proofs).  Only  three  of  these  arithmetical  lemmas  (those  marked 
by  a "*")  are  needed  to  prove  that  the  program  halts  within  1LOC4(B20)  executions 
of  the  loop.  This  reflects  the  fact  that  the  loop  is  controlled  by  a single  instruction, 
B2:“B2  DIV  4.  So  termination  is  a much  simpler  problem  than  correctness  of  the 
output  in  this  case,  and  can  be  checked  almost  for  free  . 


GOALFILE 


AX 1 Oh  @P1<@P2  - P1+1<P2; 

GOAL  ®P1<®P2  SUB  (P1<®P3) a (@P3<P2) ; 

GOAL  0 < ®X  + ®Y  SUB  (0  S X)  a (0  < Y) ; 

GOAL  ®P1<«P2  SUB  (P1<@P3) a(@P3-P2)  ; 

AX l OH  IF (I *J)  THEN  ®!>®J  - I>J; 

GOAL  POWER  0F_F0UR (@U  01 V 4) SUB  P0UER_QF_F0UR (ID; 

GOAL  1 < («I  01 V 4)  SUB  POWER _0F_F0UR ( I ) a ( 1 < I ) ; 

AXIOn  (@K*@L)01V  ®K  « L; 

AXIOh  IF  n+l<K  THEN  ((@K*@L)+@n  )DIV  @K  « Lj 
GOAL  0<®P1  DIV  @P2  SUB  (P2  > 0)a(P1  > 0); 

GOAL  EVEN  (@Z)  SUB  (Z*Z=A2*@X) aP0UERJ3F_F0UR (X) ; 

AXION  IF  EVEN (X)  THEN  (@X  CIV  2)*(®X  01 V 2)  « (X*X) 0 1 V 4; 
AXION  IF  P0UER_0F_F0UR (X)  THEN  ®Y*(@X  01 V 4)  **  (Y*X)01V  4; 

GOAL  (®X  01 V ®I)«(eY  01 V @1)  SUB  X*Y; 

AXIOM  IF  EVEN (X)  THEN  4*(®X  01 V 2)  «*  2*X; 

AXIOH  IF  P0WER_0r- _F0UR ( I ) THEN  4*(®I  01 V 4)  « I; 

GOAL  ®X*©Y=@Z*®Y  SUB  ( Y^0)  3 (X«=Z) ; 

GOAL  IL0G4 (®X) >0  SUB  X>1; 

AXION  IL0G4 (®X  0IV  4)  **  IL0G4 (X) -1 ; 

GOAL  IL0G4 («X) si  SUB  (X>1) aP0WER_0F_F0UR (X) ; 
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The  next  example  shows  how  the  termination  of  a recursive  procedure  can  be 
proved  using  a counter  and  the  entry  assertion  which  states  a bound  on  the  value  of 
the  counter.  The  procedure  PCCD  computes  the  greatest  common  divisor  of  M and  N 
and  returns  the  value  as  R.  This  is  stated  as  the  exit  assertion. 

PASCAL 


PROCEDURE  PGCD  (VAR  COUNTER, R:  INTEGER;f1,N:  INTEGER) ; 

ENTRY  (t1>0)  a (N>0)  a (COUNTER<N0)  a (CGUNTER+NSN0) ; 
EXIT  R*GCD(N,N) ; 

BEGIN 

COUNTER  COUNTER+1; 

I s-  nOD(tt,N); 

IF  1-0  THEN  R N ELSE  PGCO (COUNTER, R,N, I ) 
END; 


***** 


FOR  PGCD 

THERE  ARE  2 VERIFICATION  CONDITIONS 


U 1 

(nOD(N,N)o0  & 
0<n  & 

0<N  & 

COUNTER<N0  & 
COUNTER+N<N0 


N-GCD (M,N) ) 


U 2 

(-MDD (d, N) -0  & 
0<n  & 

0<N  & 

COUNTER<N0  & 
CGUNTER+N<N3 


0<N  & 

0<NOD(n,N)  & 

COUNTER+1 <N0  & 
COUNTER+l+nOD(H,N)sN0  & 
(R00=GCD(N,MQO(N,N) ) 


R00-GCD(M,N))) 
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*** 


These  verification  conditions  are  simplified  to  TRUE  using  the  following  arithmetic 
lemmas  and  lemmas  describing  properties  cf  GCD(X,Y).  The  computation  took  6 CPU 

seconds. 

GOALFILE 

AXIOM  0 5 MOD (®M,®N)  « TRUE; 

AXIOM  M0D(8M,®N)+1  < ®N  - TRUE; 

AXIOM  IF  X-Y*«Q  THEN  M0D(®X,®Y)  ~ 0; 

GOAL  ®P3  s ®P1+®P2  SUB  (P3sPl) a(0sP2) ; 

AXIOM  ®P1<«P2  « P1+1<P2; 

GOAL  ®X  5 «Y  SUB  (X-1*Y)  a (X-lsY)  ; 

GOALFILE 

AXIOM  IF  Y-MOD (®R, X)  THEN  GCD(@X,®Y)  » GCD(R.X); 

AXIOM  IF  MOD (X, Y) «0  THEN  GCD(«X,«Y}  « Y; 


- 21  - 


The  last  example  is  the  procedure  SIFTUP  used  in  the  TREESORT3  algorithm. 
The  properties  that  the  output  array  is  ordered  and  the  output  array  is  a 
permutation  of  the  input  array  have  been  proved  for  the  whole  TREESORT3 
algorithm  by  this  verifier  [Suzuki  75a].  We  verify  here  that  SIFTUP  terminates  and 
the  computation  time  required  is  proportional  to  the  logarithm  of  the  size  N/10. 
PASCAL 


PROCEDURE  SIFTUP  (I0.N: INTEGER) ; 

ENTRY  (K=  IL0G2  (01 V (N,  10) ) ) a(COUNTER-0)MK£0)  ; 
EXIT  COUNTERsK+1; 


VAR  COPY: REAL;  J,  I. INTEGER; 
BEGIN 


I - 10;  COPY  v nil); 

10:  J «-  2 * I ; 

ASSERT  (COUNTER-  IL0G2  (01 V ( 1 , 1 0) ) ) a (COUNTERS)  a 
(K-IL0G2 (01 V (N, 10) ) ) a(J-2#I ) ; 

C0UNTER-C0UNTER+1; 

IF  J S N THEN 
BEGIN 

IF  J < N THEN 
BEGIN 

IF  flU+1)  > ri[J)  THEN  J - J+l 
END; 

IF  HCJ3  > COPY  THEN 

BEGIN  HU)  v MCJ1 ; I «•  J;  GO  TO  10  END; 

END; 

run  - copy; 

END;.; 


***** 


FOR  SIFTUP 

THERE  ARE  8 VERIFICATION  CONDITIONS 


U 1 

(K=ILQG2 ( 0 1 V (N, 10) ) & 
COUNTER-0  & 

0<K 


COUNTER- I L0G2 (D IV (10,10))  & 
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> 

COUNTERS  & 

K=1 L0G2  (D I V (N , 1 0) ) & 
2*1 0=2*1 0) 

• 

n 2 

(COPy<mu+13  & 

n[j]<nu+i]  & 

J<N  & 

J<N  & 

COUNTER- 1 L0G2 (01 V 1 1 , 1 0) ) & 
COUNTER<K  & 

K-l L0G2 (01 V (N,  I 0) ) & 

J-2*I 

-4 

COUNTER+l-I L0G2 (01 V (J+l,  10) ) & 
C0UNTER+1<K  & 

K *- 1 L0G2  (0 1 V (N,  10) ) & 

2* (J+l) -2* (J+l) ) 

tt  3 

(C0PY<n[J3  & 

-n[j]<nu+ii  & 

J<N  & 

J<N  & 

C0UNTER-1L0G2  (01  V(1 , 1 0) ) & 
COUNTERS  & . 

K-IL0G2  (0 1 V (N,  10) ) & 

J=2*I 

' 

*4 

COUNTER+1 « 1 L0G2 (0 1 V ( J # 10) ) & 
CQUNTER+1<K  & 

K-l L0G2  (01 V (N, 1 0) ) & 
2*J»2*J) 

1 

j 

U 4 

(C0PY<11  [J]  & 

-J<N  & 

J<N  & 

COUNTER- 1 L0G2  (01  V(1 , 10) ) & 
COUNTERS  & 

K-l L0G2  (01 V (N, 1 0) ) & 

J-2*I 

C0UNTER+1  = IL0G2(0IV (J,  10) ) & 
C0UNTER+1<K  & 

K-l L0G2 (01 V (N, I 0) ) & 
2*J-2*J) 

U 5 

(-C0PY<hfJ+13  <S 
n[j]<nrj+i3  & 

COUNTER- 1 L0G2 (D1V (1 , 10) ) & 

COUNTER <K  & 

K *=>  l L0G2  ( D l V (N,  10) ) & 

J-2*l 

**COUNTER+l<K+l) 
tt  6 

{-COPY<MU3  & 

-n[j]<ncj+i]  & 

J<N  & 

J<N  & 

COUNTER- 1 L0G2 (01 V(l , 10) ) & 

COUNTERS  & 

K-1LOG2(OIV(N,10))  & 

J=2*I 

-4 

C0UNTER+1<K+1) 
ti  7 

(-COPYcMUJ  & 

~’J<N  S 
J<N  & 

COUNTER- 1L0G2 (DI V (1 , 10) ) & 

COUNTERS  & 

K = IL0G2(0I V (N, 10) ) & 

J=2*l 

C0UNTER+1<K+1)  . 

n 8 

(->J<N  & 

C0UNTER-IL0G2 (Df V(l , 10) ) & 

COUNTERS  & 

K=  IL0G2  (01 V (N, 1 0) ) & 

J-2*I 

"cOUNTER+lsK+l) 

***** 

The  time  required  to  verify  tnese  verification  conditions  is  24  CPU  seconds,  using  the 
following  lemmas. 


GOALFILE  • 

AXIOM  DI V (®X,»X)  - 1} 


GOALFILE 

AXIOM 


IL0G2(1)  - 0; 
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AXIOM  IL0G2(DIV(2*®A,®B) ) *♦  I L0G2 (D I V (A , B) ) + 1; 
AXIOM  IL0G2(DIV(2*®A+l,fflB) ) « I L0G2 (DI V (A , B) ) + 1; 
GOAL  IL0G2 (aX)  +1  S IL0G2 (®Y)  SU3  2 *X  <;  Y; 


In  these  examples  here,  and  in  many  others,  it  turns  out  that  termination  (and  indeed 
accurate  time  bounds)  are  much  easier  to  verify  than  the  intended  properties  of  the 
output.  If,  as  seems  frequently  to  be  the  case,  the  halting  of  the  program  is 
straightforward  (and  is  not  the  "real"  verification  problem)  this  method  of  virtual 
programming  presents  an  ?asy  and  natural  way  to  obtain  a quick  check  of 
termination  and  a verification  of  time  estimates. 
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